In recent years, many companies and government agencies have been exposed to negative press and legal proceedings due to high-profile security breaches in which sensitive data has been either inadvertently disclosed or stolen. While many of these incidents were the result of human error, a significant percentage was traced back to poorly designed software architecture and/or applications. Conventional techniques for testing software applications can identify many vulnerabilities, but no one methodology is failsafe. Furthermore, although many security-analysis techniques require significant time and resources to administer, not every application necessitates the same level or degree of analysis.
As a result, companies face a difficult trade-off between the desire to test software and limitations on available resources and time. Moreover, many companies do not have the expertise to apply some of the more intricate and complex security assessment techniques, and thus look to industry experts for such services. This creates yet another challenge, in that often what is being tested is highly sensitive, proprietary software.
There are a myriad of testing and assessment techniques for validating various properties of software applications and network implementations. However, one of the most critical processes for ensuring that the deployment of software does not expose an organization to unacceptable risks is security and vulnerability testing. Some of the conventional techniques used to perform such testing includes static analysis (automated code review), dynamic analysis (automated penetration testing) and manual analyses such as code review, design review, and manual penetration testing. All of these analysis techniques are aimed at finding security weaknesses and vulnerabilities in an application and typically provided in report format to the programmers, product managers and quality assurance (QA) staff. The report can provide detailed results (e.g., program names, line numbers, variable names, data connections, etc.) as well as a summary of the results. The report may be a conventional document such as a text file or a structured XML file.
However, once the report is run and reviewed by a QA engineer or product manager, it is typically no longer referenced or used. Furthermore, as an executable or application is implemented and/or provided to a customer, the report is forever decoupled from the software that was tested. In fact, an individual or organization using software has no knowledge that a report was ever created or used to analyze the software they are now using. As such, valuable information about what aspects of the application were tested, how secure certain features or functions may be and what testing methodologies were used are unknown to those that value such information.
Another trend in systems engineering is the use of so-called “virtual machines.” Generally, a virtual machine (or “VM”) refers to completely isolated operating system installation within a normal operating system, which may be implemented either using software emulation or hardware virtualization. More specifically, virtual machine is a software implementation of a physical machine (i.e., a computer) that executes programs in the same manner as the machine itself. VMs utilize an “image file” to store a snapshot of a complete computer system, including all required information describing the computer system such as the operating system, applications, data and all configuration information.
Virtual machines are typically separated into two major categories based on their use and degree of correspondence to a real machine. A system virtual machine provides a complete system platform which supports the execution of a complete operating system, such as Linux or Windows. In contrast, a process virtual machine is designed to run a single program, essentially supporting a single process. An essential characteristic of a virtual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machine. As such, the “file” containing the VM is a complete and closed environment.
What is needed, therefore, is a system and associated techniques that can produce vulnerability and security test reports using various testing methodologies for virtual machines.